Embed the corgea skill in the binary and expose it via corgea skill show - #152

An agent reading the skill from a branch or a registry can be told about
flags the installed CLI does not accept. Compiling skills/corgea/SKILL.md
into the binary makes the reference pinned to the version being driven,
by construction.

corgea skill show prints it verbatim. It is dispatched without the token
check that guards install, because reading a compiled-in string cannot
need a login, and the point is that it still answers when the registry
does not.

install --local writes the same content, refusing a name other than
corgea or an explicit version since neither is something the binary can
honour. The registry path is unchanged and still serves company-authored
skills.

Co-authored-by: Cursor <cursoragent@cursor.com>

The early return added for `skill show` only covered that one command, so
`skill install corgea --local --dir <writable-dir>` still reached the
unconditional `Config::load()` and panicked creating ~/.corgea/config.toml.
The embedded path needs neither a registry nor a token, so the local
installer was unusable in the same sandbox `skill show` was fixed for.

Replace the special case with one rule: `Config::load_or_defaults()` falls
back to in-memory defaults, and `tolerates_unusable_home` decides which
commands get it. Only the two that serve the compiled-in skill qualify;
everything else still fails loudly, because it needs a token or somewhere
to save one.

The existing tests only read the embedded constant, so they survived every
regression this PR guards against. Add binary-level tests that drive the
real executable with no token under an unusable HOME and compare the bytes
it prints and writes against skills/corgea/SKILL.md. Reverting the config
guard fails four of them; removing the --local auth bypass fails five.

`load_or_defaults` called `load()`, which creates ~/.corgea and writes
config.toml as a side effect of resolving its path. So `skill show` began
persisting state on a writable home -- a regression against the early return
it replaced, and a contradiction of its own comment. It also inherited the
`.expect()` on the TOML parse, so a config the user had merely mistyped took
down the commands that exist to work when nothing else does.

Read the file directly instead, through a `config_path_readonly` that creates
nothing, falling back to the defaults when it is absent, unreadable or
unparseable. `load()` now returns a parse failure as an `io::Error` naming the
file rather than panicking, and `main` prints that and exits 1: a file the
user can edit is their problem to fix, not a crash with a backtrace note.

The tolerance is scoped to the embedded path. A command that needs the config
still refuses to run on one it cannot parse.